Mark the FunctionCall/ResultContent.Exception properties as [JsonIgnore] #5492
Conversation
test/Libraries/Microsoft.Extensions.AI.Abstractions.Tests/Contents/FunctionCallContentTests..cs
Outdated
Show resolved
Hide resolved
stephentoub
force-pushed
the
jsonignoreexception
branch
from
c24ba7f to
bed5e4b
Compare
Given implementation details of the JSON source generator today, even with the converter applied to these properties, code is still being generated for Exception, leading to unsuppressable trimmer warnings.
stephentoub
force-pushed
the
jsonignoreexception
branch
from
bed5e4b to
57c51b7
Compare
| /// information to an AI service, a human-readable representation of those conditions should be supplied. | ||
| /// </param> | ||
| /// <param name="exception">Any exception that occurred when invoking the function.</param> | ||
| public FunctionResultContent(string callId, string name, object? result, Exception? exception) |
There was a problem hiding this comment.
Why do we need to expose a ctor overload accepting Exception given that the property is settable?
There was a problem hiding this comment.
Trying to avoid breaking binaru changes right now if they're not necessary.
There was a problem hiding this comment.
Sure, but if we can't make them now it will be even more difficult to make them later.
There was a problem hiding this comment.
I'd rather take any such changes in batch when we have a meaningful set, do a more thorough review based on received feedback, etc. Force people to rev fewer times.
There was a problem hiding this comment.
Will we remember/have enough context to remove this constructor when such a review is going to be made? Unless we release new bits to customers on a very frequent basis I don't see how postponing such a decision would impact churn substantially.
There was a problem hiding this comment.
Each one of these is a binary breaking change. If every single release makes such a change but is binary breaking, it effectively means that the ecosystem gets reset with every single release. At a minimum these are shipping monthly now along with the rest of dotnet/extensions.
There was a problem hiding this comment.
I understand, but at the same time this seems fair game or even expected when evolving previews.
There was a problem hiding this comment.
Removing this constructor is not a meaningful fix. It doesn't improve what someone is able to do. All it does is force someone to use a different syntax to construct it. Why would we want to reset the ecosystem for such a change? When there are other binary breaking changes we decide to make in preview, then we can make this at the same time, but I don't see the value in just making this one. And shipping will be frequent enough that it very well could be the only one.
Given implementation details of the JSON source generator today, even with the converter applied to these properties, code is still being generated for Exception, leading to unsuppressable trimmer warnings.
Closes #5483
Microsoft Reviewers: Open in CodeFlow